PCI DSS 3.2.1 に対応するAWSセキュリティ対策

PCI DSS対応を行い高セキュリティなシステムを構築するにはどうすればいいでしょうか

#PCI-DSS

#セキュリティ

#AWS Well-Architected Tool

#AWS Well-Architected

#AWS Well-Architected Framework

吉井亮

2020.07.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井亮です。

AWS 上で決済系システムを稼働させることはすでに珍しくありません。今後も事例は伸びていくと想像します。

AWS で稼働させることのメリットは多くありますが、一番のメリットは 高セキュリティ だと考えています。物理セキュリティはデータ－センター事業社のなかでもトップクラスの堅牢さではないでしょうか。 PCI DSS 要件9 「カード会員データへの物理アクセスを制限する」は AWS が取得している認定にオフロードすることが可能です。

論理セキュリティは決済事業社で担保する必要がありますが、AWS サービスをしっかり活用すればセキュアなシステムを構築可能です。本エントリではその辺りを記述していきます。

ソース

公式が公開している情報を基に記述しています。詳しく知りたい方は公式の情報を参照して頂くと理解が深まると存じます。

PCI コンプライアンス AWS での PCI DSS - クイックスタート PCI DSS スコーピングおよび AWS 上でのセグメンテーションのためのアーキテクチャの設計の日本語版のホワイトペーパー

責任共有モデル

まずは AWS の責任共有モデルを理解することが大切です。

https://aws.amazon.com/jp/compliance/shared-responsibility-model/ より引用

AWS の責任範囲内は、AWS が責任を持って管理運用します。安心して任せましょう。

上図で「お客様」となっている部分はご自身で管理運用します。ここでよく考えるべきことは、インフラを抽象化する、つまり、マネージドサービスを活用することで責任範囲を AWS に寄せることができるということです。自社の監査範囲を狭めるのはとても有効な手段だと考えます。

PCI DSS 適用範囲の識別

CHD を受信、処理、保存、送信する AWS リソースと PCI DSS 適用範囲を識別します。

マネージドサービスを使う場合の適用範囲はどうなるでしょうか？ RDS に CHD を保存する場合、適用範囲は保存されているテーブルを含むスキーマになると思います。 (アクセス権限が適切に設定されている前提です)

EC2 の場合は従来の仮想サーバーと同じ考えでほぼ問題ないと思います。 CHD を受信、処理、保存、送信するサーバーであれば適用範囲になります。

セグメンテーション(分離)

セキュリティ境界を設計し適用範囲内外を正しく分離すると、適用範囲を可能なかぎり少なく構成することが可能です。

AWS アカウントによる分離

最もわかりやすく分離する方法が AWS アカウントを分けることです。 AWS アカウントは別アカウントのリソースと論理的に分離されています。明示的に接続する設定を行わない限りリソース同士が接続することはありません。

以下のような AWS アカウント構成を例示します。

CDE システムが稼働するアカウント
直接の処理は行わなくても CDE システムを管理・補佐するシステムが稼働するアカウント
決済システムとは全く関係ないシステムが稼働するアカウント

ネットワーク層による分離

Security Group、または、NACL で分離します。 Security Group の初期値ではアウトバウンドは全て許可になっています。PCI DSS の要件を満たすためにはアウトバウンドも厳密に制限することに留意ください。

アプリケーション層による分離

可能な限りサーバー間通信は API Call を利用して行うようにします。具体的には API Gateway を利用します。 CDE システムとそれ以外のシステム間の CHD 以外のデータを API Gateway を介して行うことで適用対象を限定することが可能です。 ※ API Gateway を介しても CHD やセキュリティ上関連のあるデータが流れる場合は適用対象となります。

コンテナでの考え方

金融業界でも利用が増えてきているコンテナを使う場合は適用対象と適用対象外を別々のクラスタ・タスクに分離します。

Security Group を使い正しくネットワーク境界を設定します。

侵入テスト

外部境界(公開されている部分)、内部境界(VPC 内)、VPN などの接続に対して侵入テストを行うことになるはずです。

マネージドサービスに対する侵入テストは必要ありません。 AWS が取得しているサービスプロバイダ評価に含まれています。

予防的な統制

一度設定したセキュリティが意図的または事故的に穴が空いてしまわないように予防的な統制を導入します。 CloudTrail、Config、Config Conformance Packs、Security Hub、Access Analyzer

PCI DSS コンプライアンスガイド

それでは PCI DSS 要件ごとに活用すべき AWS サービスを考えてみます。

要件1：カード会員データを保護するために、ファイアウォールをインストールして構成を維持する

これらのサービスを活用しネットワーク境界を強化します。

サービス	活用方法
VPC	場合によっては適用対象と適用対象外で VPC を分けることも検討します。
VPC Endpoint	VPC Endpoint を使い AWS サービスとの通信が VPC 内で完結するように構成します。
Security Group	認められた送信元だけを許可し、ネットワーク境界を明確にします。アウトバウンドの制御も忘れずに。
NACL	Security Group では満たせない通信要件は NACL を使い実現します。
NAT Gateway	プライベートサブネットに配置した EC2 から VPC 外のシステムへの通信が必要な場合に使います。
RouteTable	プライベートサブネットから意図しない通信が他サブネットに流れないよう適切にルートテーブルを設定します。
ALB	クライアントからインターネットを経由して CHD が流れてきます。リスナーのセキュリティポリシーで

要件2：システムパスワードおよびその他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない

ベンダーのデフォルトを使用しない

EC2 で使うキーペアは自身で作成した鍵を使います。マネジメントコンソールから簡単に作れますが、そのキーペアは使わないようにします。

AWS アカウントを申し込むと作成されるルートユーザーは厳密に管理し通常利用はしないようにします。 IAM ユーザーまたはロールを使用するようにします。 IAM パスワードポリシーは自組織のポリシーに合わせてデフォルトから変更します。

セキュリティ標準の導入

セキュリティ標準を導入しそれをメンテナンスしていきます。 AWS ではセキュリティ標準への準拠を機械的にチェックするサービスがあるので活用します。

Trusterd Advisor
Security Hub
Conformance Packs

また、AWS Security Best Practices や、Well-Architected フレームワークセキュリティの柱といったドキュメントを参考にして自組織のセキュリティポリシーを策定するのも有効です。

非コンソールマネジメント

全てのリモート管理は暗号化された通信を用います。(SSH、HTTPS、VPNなど)

AWS マネジメントコンソール、または、AWS CLI を用いて管理作業を行う場合でも、CHD から遠ざけるよう IAM ポリシーを厳密に設定します。

インベントリの収集

AWS リソースのインベントリを収集し最新状態を把握しておきます。 AWS リソースであれば Config、OS 内情報であれば Systems Manager インベントリを活用します。

要件3：保存されたカード会員データを保護する

AWS が提供しているマネージドなデータベースは転送時、保管時の暗号化をサポートしています。暗号化を有効にして使用します。暗号化キーは KMS または CloudHSM を使って管理します。

KMS では自動的なキーローテションを行います。また、IAM ポリシーを正しく設定し、KMS へアクセスできるユーザーやロールを制限します。

KMS への API コールは CloudTrail でロギングします。

要件4：オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する

外部からインターネット経由で CHD を受信する場合には、CloudFront、ELB、API Gateway を経由するように構成し、TLS 1.1 以上を採用します。 PCI DSS v3.2.1 では TLS 1.1 以上となっていますが、CloudFront、ELB、API Gateway で使用可能な最新 TLS バージョンを採用することをおすすめします。

AWS サービスとの通信は可能な限り VPC Endpoint を経由するように構成します。 VPC Endpoint を経由する通信は AWS 内に留まることになり「オープンな公共ネットワーク」には該当しなくなります。

AWS SDK を使ってクライアントアプリケーションを使用している場合は、その SDK で TLS 1.1 以上を使えるようコーディングしているかをご確認ください。

要件5：アンチウィルスソフトウェアまたはプログラムを使用し、定期的に更新する

EC2 でアプリケーションを動作させている場合は、アンチウィルスソフトウェアを導入します。

AWS が提供しているマネージドサービスは AWS が責任を持ってアンチウィルス/マルウェア対策を行います。

要件6：安全性の高いシステムとアプリケーションを開発し、保守する

脆弱性に対するパッチが公開されたらなるべく早く適用します。脆弱性にチェックは Inspector が役に立ちます。

EC2 へのパッチ適用は Systems Manager Patch Manager を使い自動化します。

AWS Code シリーズを使いアプリケーションの CI/CD パイプラインを構築します。デプロイの自動化・高速化は高セキュリティを保つために必要です。

本番環境とそれ以外の環境は分離します。 AWS アカウントの分離をまず考え、それが難しい場合は VPC を分離します。

アプリケーションの脆弱性対策はご自身の責任になります。コードの中でバッファオーバーフロー、暗号化、XSS、CRSF などの対策を行います。

AWS WAF を導入してインターネットに面しているアプリケーションを保護します。 AWS が提供しているマネージドルール、ベンダーがマーケットプレイスで提供しているマネージドルールのなかから要件に合うものを選定します。

要件7：カード会員データへのアクセスを、業務上必要な範囲内に制限する

IAM ユーザー/ロール/ポリシーを使いアクセス権限を正しく設定します。職責ごとに必要なアクセス権限を設定します。

AWS アカウントを申し込むと作成されるルートユーザーは厳密に管理し通常利用はしないようにします。ルートユーザーには必ず MFA を設定するようにしましょう。

要件8：コンピュータにアクセスできる各ユーザに一意の ID を割り当てる

IAM ユーザーは一人一つが大原則です。複数人での使い回しは禁止です。 IAM ユーザーのパスワードポリシーは複雑なものを設定します。また、IAM ユーザーは MFA を設定します。

90日間ログインのない IAM ユーザーは削除します。このチェックは Security Hub や Config で行います。

マネジメントコンソールにしても CLI にしてもスイッチロール運用を採用します。ロールにはタイムアウト時間を15分に設定します。

CHD が保管されている RDS や S3 はマネジメントコンソールまたは CLI でのデータ許可を禁止します。システム上必要なアプリケーションからのみデータアクセスを許可します。

要件9：カード会員データへの物理アクセスを制限する

AWS リソースに関する物理的セキュリティは AWS の責任で管理されています。

要件10：ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する

AWS が提供する各サービスの監査ログを有効にします。以下は例です。

CloudTrail (S3 含む)
RDS Audit
VPC Flow Logs
Lambda 関数のログは CloudWatch Logs へ
EC2 内のログは CloudWatch Logs へ (要 CloudWatch Agent)
CloudFront アクセスログ (Firehose 経由 S3)
ALB アクセスログ

EC2 の NTP サーバーは Amazon Time Sync Service を指定します。 Time Sync の IP アドレスは 169.254.169.123 です。(執筆日時点)

S3 にデータを保管する場合はバージョニング、ライフサイクル、MFA Delete を有効にします。長期保管が必要だが参照がほぼ無いファイルは Glacier などの安価なストレージへの移行を検討します。

監査ログを検索・表示できる仕組みを用意します。グラフィカルに表示するなら Amazon Elasticseach、QuickSight を検討します。テキスト検索なら CloudWatch Logs Insights、Athena で検索できる構文を用意しておきます。

要件11：セキュリティシステムおよびプロセスを定期的にテストする

侵入テスト・検知

AWS で侵入テストを行う前に利用規定とテストポリシーを確認しておきます。許可されている動作、禁止されている動作を理解し、禁止されている動作をしないように留意します。

AWS Acceptable Use Policy 侵入テストの AWS カスタマーサポートポリシー

EC2 への侵入を検知するには、別途 EC2 にバーチャルアプライアンスを構成するか当該 EC2 にホストベースの IDS/IPS 製品を導入します。

AWS アカウント内の脅威を検出するために GuardDuty を全リージョンで有効にします。 GuardDuty は VPC Flow Logs、DNS Logs、CloudTrail を裏側でモニターし脅威と思わる挙動を検知します。

変更検知

Config によってリソースの変更を記録することが可能です。あるリソースとそれに関連するリソース (例えば、EC2 と Security Group) の設定変更履歴を表示可能です。

CloudTrail と CloudWatch Events を組み合わせると変更を通知することが可能になります。 CloudTrail 画面にテンプレートが用意されていますのでご活用ください。

要件12：すべての担当者の情報セキュリティポリシーを整備する

セキュリティポリシーとこれまで設定したシステムを維持します。

AWS では AWS 環境内でセキュリティイベントに対応するための基本概要を公開しています。ご一読ください。 AWS Security Incident Response Guide

まとめ

いかがでしたでしょうか。 PCI DSS 準拠のうち AWS インフラに関わる部分を記述してみました。扱うデータがセンシティブなだけにセキュリティも細かく対策が必要です。 PCI DSS に関連が無いシステムにおいてもセキュリティ対策は参考にできると思います。

参考

PCI コンプライアンス AWS での PCI DSS - クイックスタート PCI DSS スコーピングおよび AWS 上でのセグメンテーションのためのアーキテクチャの設計の日本語版のホワイトペーパー [アップデート] Security Hub に PCI DSS にあわせた自動セキュリティチェックが追加されました！ AWS Security Best Practices Well-Architected フレームワークセキュリティの柱 AWS Security Incident Response Guide Well-Architected Frameworkの柱「セキュリティ」を読み解いてみた

以上、吉井亮がお届けしました。

PCI DSS 3.2.1 に対応するAWSセキュリティ対策

ソース

責任共有モデル

PCI DSS 適用範囲の識別